A “zero downtime maintenance” approach to a business software application can include a mechanism for deploying a software change to a productively used system in a manner that eliminates time during which the entire system is not available to users. Software changes can include those provided by a software vendor or other provider of a business software application (e.g. as part of a software update, correction, or upgrade) and/or those created by a development team or other members of a customer organization that uses the business software application (e.g. as customizations, integration with other software components, etc.). In general, a software change can include (but is not limited to) a support package, a new release, a modification of customer code, etc. The term business software application is used herein to refer to a software configuration including one or more software components that support business functions, such as for example human resources, payroll, enterprise resource planning (ERP), or the like. A productively used system generally includes one or more servers or other machines (e.g. an application server infrastructure) upon which at least some features of the business software application are implemented, and which are available for business use by users at one or more customer organizations.
Current approaches to zero downtime maintenance generally do not guarantee availability of the full scope of the business application or the application server infrastructure during the complete deployment process for the software change. Rather, the productive system can generally be maintained in an “up and running” state all the time, but the usable scope may be reduced for at least some of the time required for the deployment process. For example, certain database tables may not be accessible for write operations during some part of the deployment process, some functions may only be available “read-only,” etc. The scope and duration of these access limitations can generally be defined by the deployed software change, and thus generally depend on the kind of software change occurring as well as the capabilities of the procedure.